上一篇文章，我談到功能出問題時，怎麼讓使用的人知道發生了什麼，以及接下來可以怎麼做。

不過，在把功能交到成員手上之前，還有一個更早的問題。

我要怎麼知道它已經可以使用？

最直覺的方式，是自己操作一次。按下按鈕，看到預期結果，沒有跳出錯誤，就覺得差不多完成了。

這當然是必要的一步。但前兩篇談過的重複點擊、連線中斷與處理到一半失敗，通常不會剛好在第一次試用時全部出現。

成功一次，能證明那次操作走得通。

至於換個人、換個時間，或中間出了狀況之後，還能不能正確處理，就需要另外確認。

先說清楚，什麼結果才算完成
如果連預期結果都沒有說清楚，測試很容易變成「看起來有動就好」。

以購買功能為例，完成不只是角色回覆一句「購買成功」。

還需要確認金幣扣得正確、商品交付到正確的帳戶、交易紀錄能查到，而且同一笔操作不會因為重試再做一次。

這些結果最好在開始製作之前，就先整理出來。

我可以用比較接近使用者的方式描述：

「符合條件的人，可以用已確認的價格買到指定商品。購買失敗時，不會留下不明的扣款；結果尚未確認時，也不會引導他重複購買。」

接著再把這段話拆成能檢查的情況。

這樣測試的對象就不只是某個按鈕，而是功能答應使用者的事情。

正常情況，只是其中一條路
一個功能通常有一條最順利的操作路線。

使用者資料齊全、權限正確、餘額足夠，所有服務也都正常。程式從頭走到尾，得到預期結果。

我一定要確認這條路，但不想只停在這裡。

如果餘額不足呢？商品已經下架呢？有人按到另一位成員的操作按鈕呢？提交內容缺了一個必要欄位呢？

這些情況不一定代表程式壞掉，卻都需要有合理的結果。

該拒絕的操作，要確實拒絕；可以補資料的情況，要指出缺少什麼。不能因為沒有走在最理想的路線上，就留下難以理解的畫面，或改動不應該改動的資料。

用預先安排的情境，取代等待意外發生
我不需要真的等到外部服務故障，才知道程式會怎麼處理。

測試時，可以安排一個會回傳錯誤的替代服務，或在指定步驟模擬中斷，觀察接下來的結果。

例如，刻意讓交付失敗，確認扣款是否依照設計退回，或留下可繼續處理的狀態。也可以讓通知送出失敗，確認已完成的交易不會因此被重新執行。

這些安排的目的，是把平常不容易遇到的情況，變成可以重複檢查的情境。

不過，替代服務也有它的限制。如果它的行為和真正使用的服務差太多，測試通過就可能只代表程式能應付自己設定的假想世界。

所以，我仍然需要確認實際介面與限制。能模擬的先模擬，需要整合驗證的部分，再放到適合的隔離環境裡檢查。

不只看回覆，也要看背後留下什麼
畫面顯示成功，不表示所有資料都正確。

畫面顯示失敗，也不表示系統完全沒有變更。

因此，我希望測試能同時檢查回應和實際狀態。

購買之後，除了看訊息，還要查帳戶、背包與交易紀錄。被拒絕的操作，也需要確認沒有偷偷留下扣款或交付。

這些檢查最好不要全部依賴同一段回覆程式。

如果成功訊息本身就有錯，再用那句訊息證明操作成功，只是在重複相信同一個來源。回到保存結果的地方確認，才能比較清楚地知道事情究竟有沒有發生。

同時操作與重新啟動，也要列進來
有些問題，單次操作永遠看不出來。

兩個請求同時到達，可能繞過原本以為足夠的檢查。程式重新啟動後，也可能忘記哪些事情已經處理過。

所以，涉及交易或持久紀錄的功能，我會希望另外確認這些情況。

同一筆操作一起送來時，是否只有一次生效？處理中途停止，重新啟動之後能不能辨認原本的進度？舊的請求再次出現時，會不會被當成新交易？

這些不是要把每個小功能都做成大型系統，而是依照功能可能造成的影響，選擇必要的檢查。

查詢失敗和重複扣款，後果不同，測試的重點也不需要完全一樣。

自動測試和實際試用，各自看見不同的問題
自動測試適合反覆確認明確的規則。

同樣的輸入應該得到什麼結果、重複操作能不能被擋住，以及資料是否保持一致，都可以在修改後重新檢查。

但有些問題，需要真的走過介面才容易發現。

按鈕文字看不看得懂？手機上能不能找到確認入口？處理中有沒有提示？錯誤訊息雖然正確，卻是不是長到讓人找不到下一步？

因此，我不想把兩者當成互相取代的選項。

自動測試幫助我守住已知規則，實際試用則確認人能不能順利完成事情。尤其我自己太熟悉的流程，還需要想辦法用第一次接觸的角度重新走一遍。

我知道入口在哪裡，不代表它真的容易找到。

測試失敗時，不能只想著把它改成通過
測試沒有通過，可能有不同原因。

程式真的做錯了，測試對預期的理解有誤，或是測試環境缺少必要條件，都有可能。

需要先分清楚原因，再決定修改哪裡。

我不希望因為某個檢查擋住進度，就直接刪掉它，或把原本的要求放寬到目前程式剛好能做到的程度。

如果需求確實改變，可以調整測試，但要說清楚改了什麼。若原本的承諾仍然成立，就應該修正功能，讓它符合要求。

測試是用來發現問題的。只有在失敗時也願意認真看待，它才不會變成一場證明自己已經做好的形式。

找另一個人看，也不要只問「有沒有問題」
自己設計、自己製作，也自己驗證，很容易沿著同一套想法走。

我可能一直測試自己預期的使用方式，卻沒有注意到另一種很自然的操作。

因此，對影響較大的功能，我希望有另一個人或獨立的審查者，從不同角度確認。

但交出去時，不能只給一句「幫我看看」。

需要讓對方知道功能承諾什麼、哪些地方不能出錯、目前做過哪些測試，以及還有哪些限制。接著請他嘗試找出反例，而不是只照著我的成功步驟再走一次。

審查者也可能漏掉問題，所以通過審查不是永遠安全的保證。它的價值，是增加一個不完全沿用原本思路的檢查機會。

「通過了」後面，還要接著說通過什麼
如果我只說「測試全部通過」，聽起來很完整，實際上卻還少了一些資訊。

是規則測試通過，還是真正的介面也操作過？使用的是模擬資料，還是隔離環境中的整合流程？有沒有尚未確認的外部服務行為？

我希望交付時能把這些界線說清楚。

已經驗證的部分，就列出結果。還沒驗證的，就保留為限制，不把它藏在一句「應該沒問題」裡。

而且，測試結果要對應到實際要交付的版本。通過之後又修改了相關程式，就需要重新確認受影響的部分，不能沿用舊結果替新內容背書。

完成，不是再也不會出錯
我無法透過測試，證明一個功能永遠不會出問題。

但可以讓「做好了」不再只是一種感覺。

它應該代表：承諾的行為有被具體檢查，重要的失敗情境有被考慮，實際操作有走過，已知限制也有交代。

之後如果發現新的問題，也可以把它變成下一次會重複檢查的情境，避免修好一次，過一陣子又出現。

我希望把功能交到成員手上時，自己能說明它為什麼值得被使用。

不只是因為剛才按下去成功了，而是因為我知道，這次成功背後，有哪些事情已經被確認過。